Testing installation on our supported systems here: https://github.com/Botspot/pi-apps/actions/runs/11543239179
@theofficialgman it looks like some of the runners need fixing - something about not knowing how to uncompress an xz image.

Alright, so far from the testing it looks like one issue is how the debs are compressed - they cannot use the zst compression algorithm.

Nothing wrong with the runners (regarding tar.zst). Bullseye and older doesn't have deb tar.zst support (doesn't affect Ubuntu releases)

Regardless though this can't be used on the Switchroot Ubuntu Jammy/Noble releases due to upstream FEX regressions (segfault on launch on versions newer than 2407)

Maybe if Hangover uses Box64 by default it could be considered.

Nothing wrong with the runners (regarding tar.zst). Bullseye and older doesn't have deb tar.zst support (doesn't affect Ubuntu releases)

I should have clarified. This failure in noble-64bit appears to have happened before it reached the app-installation stage.

Regardless though this can't be used on the Switchroot Ubuntu Jammy/Noble releases due to upstream FEX regressions (segfault on launch on versions newer than 2407)

Maybe if Hangover uses Box64 by default it could be considered.

Hangover doesn't ship a Linux FEX build, but 2 DLLs based on FEX emulator core and I'd assume it would work on switchroot that way.
Box64 is also shipped as a DLL, but is only the default for 32-bit emulation.

Could you add a bit of usage information to the description?

Regardless though this can't be used on the Switchroot Ubuntu Jammy/Noble releases due to upstream FEX regressions (segfault on launch on versions newer than 2407)
Maybe if Hangover uses Box64 by default it could be considered.

Hangover doesn't ship a Linux FEX build, but 2 DLLs based on FEX emulator core and I'd assume it would work on switchroot that way. Box64 is also shipped as a DLL, but is only the default for 32-bit emulation.

As I said. Fex doesn't work on the mentioned systems, it segfaults on versions newer than 2407. The regression hasn't been determined yet.

Nothing wrong with the runners (regarding tar.zst). Bullseye and older doesn't have deb tar.zst support (doesn't affect Ubuntu releases)

I should have clarified. This failure in noble-64bit appears to have happened before it reached the app-installation stage.

Seems like a temporary server error or Ubuntu removed the URL. I'll check later.

Could you add a bit of usage information to the description?

I added some examples

Regardless though this can't be used on the Switchroot Ubuntu Jammy/Noble releases due to upstream FEX regressions (segfault on launch on versions newer than 2407)
Maybe if Hangover uses Box64 by default it could be considered.

Hangover doesn't ship a Linux FEX build, but 2 DLLs based on FEX emulator core and I'd assume it would work on switchroot that way. Box64 is also shipped as a DLL, but is only the default for 32-bit emulation.

As I said. Fex doesn't work on the mentioned systems, it segfaults on versions newer than 2407. The regression hasn't been determined yet.

I'm pretty sure this is only true for the Linux FEX version, a Windows version used in Hangover is likely not affected at all. Is the Linux FEX issue for Switchroot tracked somewhere?

When can the compression on the debs be fixed so that it works somewhere other than Bookworm?

I'm pretty sure this is only true for the Linux FEX version, a Windows version used in Hangover is likely not affected at all. Is the Linux FEX issue for Switchroot tracked somewhere?

@Azkali is there an open issue for the problem I have described or is it just discord discussion? I have not had any time to bisect what causes versions newer than 2407 to segfault on Ubuntu but you seem to have trouble on every fex version on fedora.

Only discussed on discord, my issue occured with some versions of FEX not all, I don't remember when it exactly happened, same thing for hangover.

When can the compression on the debs be fixed so that it works somewhere other than Bookworm?

The bullseye package is built on bullseye, and I haven't heard of issues other than on your ci. I can look into it for the next release in three weeks though.

When can the compression on the debs be fixed so that it works somewhere other than Bookworm?

The bullseye package is built on bullseye, and I haven't heard of issues other than on your ci. I can look into it for the next release in three weeks though.

I found the issue, the FEX packages are built on Ubuntu 22.04, which defaults to zstd. I can fix that easily.

When can the compression on the debs be fixed so that it works somewhere other than Bookworm?

The bullseye package is built on bullseye, and I haven't heard of issues other than on your ci. I can look into it for the next release in three weeks though.

I found the issue, the FEX packages are built on Ubuntu 22.04, which defaults to zstd. I can fix that easily.

Building debs for lower versions of linux distros on a newer distro is almost always going to cause a myriad of issues. Most common being that GLIBC requirements cannot be satisfied.

Your control file is also manually created and static in the github repo. This is unacceptable and you need to generate the dependencies and their minimum versions at compile/packaging time in order to guarantee that the builds can actually run on the installed system. Use the cpack DEB generator for that (if using a fully defined cmake project) or the underlying program that cpack DEB generator relies on dpkg-shlibdeps for generating those dependencies for any existing binary.

I should have clarified. This failure in noble-64bit appears to have happened before it reached the app-installation stage.

@Botspot The error message is a misnomer. The urls changed and have been updated now.

edit: I haven't put any effort to improve/pretty the action because it will change pretty significantly once github actions linux arm runners are generally available.

When can the compression on the debs be fixed so that it works somewhere other than Bookworm?

The bullseye package is built on bullseye, and I haven't heard of issues other than on your ci. I can look into it for the next release in three weeks though.

I found the issue, the FEX packages are built on Ubuntu 22.04, which defaults to zstd. I can fix that easily.

Building debs for lower versions of linux distros on a newer distro is almost always going to cause a myriad of issues. Most common being that GLIBC requirements cannot be satisfied.

Your control file is also manually created and static in the github repo. This is unacceptable and you need to generate the dependencies and their minimum versions at compile/packaging time in order to guarantee that the builds can actually run on the installed system. Use the cpack DEB generator for that (if using a fully defined cmake project) or the underlying program that cpack DEB generator relies on dpkg-shlibdeps for generating those dependencies for any existing binary.

I'll say it again, those FEX packages contain Windows DLLs. In case you don't know what that is, consider them binary blobs, like pictures, the don't care about GLIBC, distributions or dependencies.

Building debs for lower versions of linux distros on a newer distro is almost always going to cause a myriad of issues. Most common being that GLIBC requirements cannot be satisfied.
Your control file is also manually created and static in the github repo. This is unacceptable and you need to generate the dependencies and their minimum versions at compile/packaging time in order to guarantee that the builds can actually run on the installed system. Use the cpack DEB generator for that (if using a fully defined cmake project) or the underlying program that cpack DEB generator relies on dpkg-shlibdeps for generating those dependencies for any existing binary.

I'll say it again, those FEX packages contain Windows DLLs. In case you don't know what that is, consider them binary blobs, like pictures, the don't care about GLIBC, distributions or dependencies.

I was already aware those are windows dynamic libraries, not linux dynamic libraries. The wine debs however do contain linux binaries and need to have their control files generated. I missed that this is already the case https://github.com/AndreRH/hangover/blob/20da7093a53e3ca842d93ba8dca37da6b7c42c4d/.packaging/debian11/wine/debian/control#L63-L65 https://github.com/AndreRH/hangover/blob/master/.packaging/debian11/wine/Dockerfile#L9 so you are good there.

I'm pretty sure this is only true for the Linux FEX version, a Windows version used in Hangover is likely not affected at all. Is the Linux FEX issue for Switchroot tracked somewhere?

Now tracked here FEX-Emu/FEX#4148
We (Switchroot) are still deciding on Discord how to proceed.

The zst compression error is still an issue on Bullseye.
https://github.com/Botspot/pi-apps/actions/runs/11637595657/job/32411051344#step:3:1672

The zst compression error is still an issue on Bullseye. https://github.com/Botspot/pi-apps/actions/runs/11637595657/job/32411051344#step:3:1672

I now made a point release which solves that, 9.20.1, and pushed the change here

Consider adding a pretty important wine patch that we have been carrying in our builds.
https://github.com/Pi-Apps-Coders/files/blob/main/CompileCommands/Apps/Wine%20(x64).md
It fixes (well really works around) broken wine .desktop files that can occur on some systems. More details and link to the bug report at that link.

Consider adding a pretty important wine patch that we have been carrying in our builds. https://github.com/Pi-Apps-Coders/files/blob/main/CompileCommands/Apps/Wine%20(x64).md It fixes (well really works around) broken wine .desktop files that can occur on some systems. More details and link to the bug report at that link.

now including that patch

ping
Any other blockers?

Sorry for the wait. I just wanted to test this running something before I merged the PR.
Upon installing Hangover on my main Pi, I noticed a couple things for users to take note of. I've updated the description to include it. @AndreRH if these changes seem factual and fair to you, let me know and I will merge the PR.

It would be nice if Hangover and Wine played nice. But installing it on a system that has a wineprefix already present, it asked permission to remove and regenerate the prexfix due to the errors:

Checking Wine prefix at /home/pi/.wine...
To choose another prefix, set the WINEPREFIX variable.
Waiting 5 seconds... 
002c:err:environ:init_peb starting L"C:\windows\system32\wineboot.exe" in experimental ARM64EC mode
002c:err:module:load_arm64ec_module could not load L"C:\windows\system32\libarm64ecfex.dll", status c0000135
wine: could not load kernel32.dll, status c000007b
◢◣ WARNING: Your previously existing Wine prefix failed with an error (see above). You chose to remove it and so it will be re-generated.

@Botspot due to other obligations I can't add this currently myself but can you please add this (hangover as hidden) to both the Jetson overrides lists. Until there is a solution upstream or downstream the majority of these devices cannot run this due to their old kernels lacking currently required functionality. I don't want this to be a blocker for other devices.

@AndreRH was there a reason you removed the Winetricks components from the install script? Without it, it is harder to install DLLs needed for commonly used applications.

Users have reported issues with winetricks and hangover. So until I found time to sort it out, I 'd rather not include it